Currently, when designing an application that interacts with a hierarchical database, it is common practice to distribute the application into at least two tiers, which typically includes core services (i.e., the main services of the application) and business logic. Usually, an application programmer is required to develop these separately from the database, using a programming language and other modeling and design tools. However, there are challenges regarding management and interaction of the core services since they are stored separately from the database. With respect to management, core services are typically provided at a lower level than the business logic and there are unique considerations which apply to core services which do not apply to business logic. For example, the core services traditionally interact with the database, and since the core services reside separately from the database, there is the potential for deadlock risks, lock contention, and performance criteria. With respect to interaction, it is common for business logic and core services to blur boundaries since there is no strict interface design. Furthermore, without an interface specifically designed for the core services, it is difficult for the user (i.e., application developer or application programmer) to make changes, update, manage or interact specifically with the core services.
Since in the current environment, core services are typically separate from the database system and the access logic does not reside on the same physical machine as the database, users may experience adverse affects such as performance issues. These performance issues may result from the compounded lock contention and latency that is typically experienced in networked environments. Additionally, since the access points are not restricted, the content of the database is potentially exposed across the network environment and as such there are security risks involved. Furthermore, since the business logic is more computationally expensive, there may be an increase with respect to the architecture costs associated with having the core services residing separately from the business logic.